The present invention relates broadly to a transaction management between software entities in a computer environment. Specifically, the present invention enables an application server to manage resource manager local transactions.
An Enterprise Information System (EIS) provides the information infrastructure for an enterprise utilizing a computer system having a client server arrangement. An EIS offers a set of services to its clients. These services are exposed to clients as local and/or remote interfaces. Examples of an EIS include enterprise resource planning (ERP) systems, transaction processing (TP) systems, and database systems. There are two aspects of an EIS: the system level services and an application specific interface.
A connector is a standard extension mechanism for application servers to provide connectivity to an EIS. A connector is specific to an EIS and consists of a resource adapter and application development tools for EIS connectivity. A resource adapter plugs into an application server through the server""s support for system level contracts. As used herein, a contract refers to the respective responsibilities two or more software entities have when interacting with each other. The Java 2 Platform, Enterprise Edition (J2EE) is the platform of choice for EISs. Two of the relevant parts are an EIS vendor-provided resource adapter and an application server that allows the resource adapter to plug in. An EIS resource provides EIS-specific functionality to its clients.
A resource manager manages a set of shared EIS resources. A client requests access to a resource manager to use its managed resources. A transactional resource manager can participate in transactions that are externally controlled and coordinated by a transaction manager. A resource manager is typically in a different address space or on a different machine from the client that accesses it. A connection enables an application client to connect to a resource manager, perform transactions, and access services provided by that resource manager. A connection can be either transactional or non-transactional.
An application component can be a server-side component, such as an Enterprise Java Bean (EJB), Java server page (JSP), or a servlet that is deployed, managed, and executed on an application server. It can also be a component executed on the web-client tier but made available to the web-client by an application server. Examples of the latter type of application component include a Java applet, or a DHTML page.
A container is a part of an application server that provides deployment and runtime support for application components. It provides an integrated view of the services provided by the underlying application server for the application components. Containers can run on existing systems; for example, web servers for the web containers, application servers, transaction processing monitors, and database systems for EJB containers. This enables enterprises to leverage both the advantages of their existing systems and those of J2EE. Enterprises can write (or rewrite) new applications using J2EE capabilities and can also encapsulate parts of existing applications in EJB or JSP. Enterprise applications access functions and data associated with applications running on EISs. Application servers extend their containers and support connectivity to heterogeneous EISs. Enterprise tools and Enterprise Application Integration (EAI) vendors add value by providing tools and frameworks to simplify the EIS integration task. J2EE provides containers for client applications, web components based on servlets, JSPs and Enterprise JavaBeans (EJB) components.
FIG. 1A shows a high level block diagram of components involved in transaction management as performed in prior client server computer systems 101 implementing an EIS 101. An application component 102 is deployed in a container 104 provided by an application server 106. The application component 102 performs transactional access to multiple resource managers 108-1, 108-2, . . . , 108-n, where n can be any number. The application server uses a transaction manager 110 to manage transactions across multiple resource managers 108. Each resource manager utilizes a corresponding resource adapter 112. Transaction manager 110 comprises a set of software modules that coordinates transactions across multiple resource managers. It also provides additional low-level services that enable transactional context to be propagated across systems. The services provided by transaction manager 110 are not visible directly to the application components 102.
In FIG. B, an application client process 114 invokes EJB X 116 in a typical transaction. EJB X 116 accesses transaction programs managed by transaction processing system 118. EJB X 116 calls EJB Y 120 that accesses an ERP system 122. EJB X 116 and EJB Y 120 access the transaction processing system 118 and ERP system 122 using respective client access APIs for the two systems. The application server 106 enlists the connections to both systems (obtained from their respective resource adapters) as part of the transaction. When the transaction commits, transaction manager 110 perform a two phase commit protocol across the two resource managers 108. This ensures that the read/write access to resources managed by both transaction processing system 118 and ERP system 122 is either all committed, or all rolled back.
The resource managers 108 can support two types of transactions. Transactions controlled and coordinated by the transaction manager 110 external to the resource manager 108 are referred to as JTA transactions or XA transactions. The second type of transaction is managed internal to the resource manager 108. The coordination of such transactions involves no external transaction managers. As used herein, such transactions are referred to as local transactions. If a single resource manager instance participates in a transaction, the application server 106 uses the transaction manager 110 to manage the transaction. However, using the transaction manager 110 has a significant performance overhead. This overhead incurs a significant processing cost in typical EISs that perform a large number of transactions. Thus, there is a need for a solution that avoids the overhead of using an XA transaction with a single resource manager.
The present invention defines a transaction management contract between an application server and a resource adapter and its underlying resource manager that allows an application server to utilize local transactions on a resource manager and avoid the overhead of an external transaction manager. As used herein, contract refers to responsibilities two individual software components have with respect to interacting with each other. The transaction management contract incorporates two aspects that apply to different types of transactions. The first aspect provides an application level transaction contract between a transaction manager and a resource manager based on javax.transaction.xa.XAResource of the J2EE specification. The J2EE specification is incorporated herein by reference in its entirety.
The second aspect is local transaction management contract. These contracts enable application server to provide the infrastructure and runtime environment for transaction management. An application component relies on this transaction infrastructure to support its component level transaction model.